На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.
Симптомы переполнения кучи, как правило, следующие:
Датасторы на хостах показывают статус "Not consumed"
Виртуальные машины не могут выполнить vMotion
Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."
В логе vmkernel.log могут появляться следующие сообщения об ошибках:
Heap vmfs3 already at its maximum size. Cannot expand
Heap vmfs3: Maximum allowed growth (#) too small for size (#)
Failed to initialize VMFS distributed locking on volume #: Out of memory
Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory
Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:
Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:
# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done
Результат будет примерно таким:
Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:
Maximum allowed growth * too small for size
Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.
На сайте проекта core.vmware.com появился интересный документ из будущего, описывающий особенности проектирования и сайзинга кластеров хранилищ vSAN, актуализированный 4 декабря этого года - VMware vSAN 7 Update 1 Design Guide:
На самом деле, документ этот очень полезен для администраторов VMware vSAN, планирующих развертывание корпоративной инфраструктуры хранилищ на базе серверов ESXi. В нем рассматриваются все новые возможности версии vSAN 7 Update 1, включая технологию HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):
Основные разделы документа:
vSAN Design Overview
vSAN Limits
Network Design Considerations
Storage Design Considerations
VM Storage Policy Design Considerations
Host Design Considerations
Cluster Design Considerations
Determining if a Workload is Suitable for vSAN
Sizing Examples
vSAN Sizing Tool
VMware vSAN GSS Support
Очень полезная вещь - это наличие рекомендаций и лучших практик по различным аспектам проектирования кластров:
Интересная табличка по рекомендациям выставления опций по реакции на событие изоляции (Isolation Responce / Isolation Policy):
Интересны также указания на часто встречающиеся ошибки проектирования:
В общем, документ мегаполезный. Скачать VMware vSAN 7 Update 1 Design Guide можно вот тут.
Компания VMware пару недель назад объявила о выпуске бета-версии операционной системы Photon OS 4.0 Beta. Напомним, что эта ОС используется сейчас уже во всех виртуальных модулях VMware (Virtual Appliances), которые реализуют различные вспомогательные сервисы. Напомним, что о прошлой версии Photon OS 3.0 мы писали весной прошлого года вот тут.
Давайте посмотрим, что нового появилось среди возможностей обновленной ОС:
1. Ядро реального времени для приложений телекома и vRAN (Virtual Radio Network)
Наступает эра 5G, и VMware сделала в Photon OS 4.0 возможности поддержки телеком-приложений реального времени на уровне ядра (Photon Real Time kernel). Это позволит технологиям vRAN (Virtual Radio Network) использовать возможности ОС Photon при развитии инфраструктуры 5G-операторов.
2. Безопасность
Photon 4.0 получила поддержку таких технологий по обеспечению безопасности, как SELinux, Security Encrypted Virtualization – Encrypted Status и Intel Software Guard Extensions. Обязательная система контроля доступа, прошитая на уровне ядра, позволяет SELinux дать администраторам гранулярный и гибкий доступ к ресурсам. Также Photon OS позволяет из коробки, на уровне политик, обеспечить нужды приложений в изоляции. Также поддерживается SELinux для контейнеров, что было протестировано для docker, containerd и runc.
Поддержка драйверов Intel SGX drivers позволяет приложениям использовать ресурсы CPU для создания "анклавов" - полностью защищенных модулей исполнения, недоступных на аппаратном уровне другим процессам.
3. Оптимизации производительности для решения vSphere with Tanzu
Исторически Photon ОС имела специальный контекст ядра linux-esx, который был специальным образом оптимизирован для работе на платформе VMware ESXi точки зрения производительности и предоставляемых возможностей. В Photon 4.0 то же самое появилось и для контейнерной среды исполнения vSphere with Tanzu, например, уменьшение времени запуска для контейнеров и приложений.
4. Улучшения компонентов ОС
В Photon 4.0 были обновлены более 700 пакетов, включая ключевые компоненты, такие как tdnf, pmd, network config manager и многие другие. Также в релиз включены превью-фичи для, которые ожидаются в финальной версии ОС. Поэтому рекомендуется не использовать бету Photon 4.0 для производственных сред.
Разработка Photon OS очень сильно опирается на участие комьюнити. Поэтому ваши комментарии, предложения и отчеты об ошибках можно добавлять вот тут.
В этом релизе, как в прошлом, ОС распространяется в бинарном предзапакованном формате - загрузочный ISO, предустановленный минимальный OVA-пакет, кастомизированный под VMware, образ Amazon AMI, образ Google GCE, образ Azure VHD, а также образ Raspberry Pi (протестированный для архитектуры ARM64).
Образы Photon OS 4.0 Beta можно скачать по этой ссылке. Публичный репозиторий доступен вот тут.
Многие администраторы VMware vSphere знают, что у этой платформы есть режим совместимости Enhanced vMotion Compatibility (EVC), который позволяет привести хосты с процессорами (CPU) разных моделей к единому базовому уровню по набору возможностей CPU Feature Set, чтобы обеспечить свободную миграцию vMotion между хостами ESXi. Делается это за счет маскирования некоторых наборов инструкций процессора через CPUID.
Сейчас многие приложения (например, реализующие техники Machine Learning / Deep Learning) используют ресурсы графического адаптера (GPU), поскольку их многоядерная архитектура отлично подходит для такого рода задач.
В VMware vSphere 7, вместе с соответствующей версией VM Hardware, были существенно улучшены функции работы для режима vSGA, который предназначен для совместного использования графического адаптера несколькими виртуальными машинами хоста.
Поэтому в VMware vSphere 7 Update 1 сделали еще одно полезное улучшение по этой теме - режим Enhanced vMotion Capabilities для графических процессоров GPU, который является частью EVC, настраиваемого в vSphere Client:
Графический режим VMFeatures включает в себя поддерживаемые возможности для 3D-приложений, включая библиотеки D3D 10.0/ Open Gl 3.3, D3D 10.1 / Open GL 3.3 и D3D 11.0 / Open GL 4.1. Пока приведение к базовому уровню доступно только до D3D 10.1 / OpenGL 3.3 (версии 11.0 и 4.1, соответственно, будут поддерживаться в следующих релизах).
Когда хост ESXi включается в кластер, где включена EVC for Graphics, сервер vCenter проверяет, что он поддерживает соответствующие версии библиотек. При этом можно добавлять хосты разных версий - ESXi 6.5,6.7 и 7.0, благодаря поддержке D3D 10.0 и OpenGL 3.3.
Как и для обычного EVC, пользователи могут включить EVC for Graphics на уровне отдельных ВМ. В этом случае перед тем, как включить виртуальную машину на хосте ESXi, сервер vCenter убеждается, что он поддерживает соответствующие библиотеки. Такая настройка полезна при возможной миграции виртуальной машины между датацентрами или в публичное облако.
Если у вас включена EVC for Graphics, то перед миграциями vMotion также будут проводиться нужные предпроверки по поддержке графических функций GPU со стороны видеоадаптера целевого хоста.
VMware на днях выпустила патч VMSA-2020-0023, который окончательно закрывает уязвимость CVE-2020-3992, имевшуюся в сервисе OpenSLP хоста ESXi. Эта уязвимость типа Use-After-Free позволяла злоумышленнику, имевшему доступ к 427 порту, получить возможность удаленного исполнения кода (эта уязвимость имела критический статус и CVS score 9.8 из 10).
VMware заявляет, что данные патчи, выпущенные 20 октября, не закрывают уязвимость полностью, поэтому нужно скачивать самые последние версии патчей:
IMPORTANT: The ESXi patches released on October 20, 2020 did not address CVE-2020-3992 completely, see section (3a) Notes for an update.
Вот сами обновления, которые были выпущены:
ESXi 7.0 - ESXi70U1a-17119627. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi_7.0.1-0.0.16850804
ESXi 6.7 - ESXi670-202011301-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi670-202010401-SG
ESXi 6.5 - ESXi650-202011401-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi650-202010401-SG
Воркэраунд, описанный в статье базы знаний KB 76372, все еще актуален. Его суть заключается в полном отключении сервиса SLP с помощью следующих команд:
/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off
На сайте проекта VMware Labs появилось очередное обновление - утилита Horizon Peripherals Intelligence, предназначенная для самодиагностики периферийных устройств пользователями решения VMware Horizon. C помощью данного средства можно проверить работоспособность и поддержку устройств как со стороны конечных пользователей, так и администраторов платформы Horizon.
На данный момент поддерживаются следующие устройства:
USB-хранилища
USB-принтеры
USB-сканеры
Камеры
В будущем будут также добавлены новые виды устройств. Сама же утилита Horizon Peripherals Intelligence служит для решения следующих задач:
Публикация отчета о диагностике устройств по запросу конечных пользователей. Сам отчет доступен админам и пользователям на веб-портале, а из него будет понятны проблемы использования устройств. В отчете будут содержаться рекомендации, на базе которых администраторы смогут предпринять определенные действия по исправлению ситуации.
Обслуживать спектр пользовательских устройств в рамках поддерживаемых со стороны официального списка совместимости device compatibility matrix. Пользовательские окружения разные (версия ОС, версия агента и т.п.) - поэтому этот момент сложно отслеживать вручную. По запросу пользователя выводится отчет о поддерживаемых устройствах в его окружении.
Для администратора предоставляется возможность получить доступ к метаданным устройств в каждой категории, где он может загружать, изменять и удалять метаданные, таким образом обслуживая матрицу поддерживаемых устройств на машинах пользователей.
Для начала работы вам потребуется:
VMware Horizon 7.x или более поздняя версия
Client OS - Windows 10
Agent OS - Windows 10, 2016, 2019
Виртуальный модуль построен на базе VMware Photon OS 3.0, что требует ESXi 6.5 или более поздней версии
Скачать Horizon Peripherals Intelligence можно по этой ссылке.
Мы уже довольно много писали о нововведениях и улучшениях недавно обновленной версии платформы VMware vSphere 7 Update 1, а также средств создания отказоустойчивых кластеров VMware vSAN 7 Update 1. Между тем, наши читатели указывают нам на интересные нововведения в части функций по работе с хранилищами в апдейте платформы (Core Storage Enhancements).
Если вы хотите подробно почитать обо всех функциях хранилищ в vSphere 7 Update 1, то рекомендуем посмотреть вот этот документ - "vSphere Storage" (но там 400 страниц, имейте в виду):
Давайте посмотрим, что из нового заслуживает внимания:
1. Улучшения VMFS
Тут 2 основных момента:
Процесс создания снапшота SESparse был улучшен - теперь он меньше раздувается, а также требуется меньше места в процессе консолидации снапшотов. Также улучшилось отображение прогресса консолидации.
Уменьшилось время "замирания" файловой системы при создании или удалении снапшотов. Это произошло за счет доработки механизма взаимодействия Affinity Manager и Resource Clusters (RC).
Поддержка томов vVols для Tanzu и Cloud Native Storage (CNS).
Оптимизация миграций виртуальных машин и операций Storage vMotion для тонких дисков - это уменьшает время, необходимое на миграцию виртуальных машин между томами vVols.
Оптимизация операций по привязке томов vVols - теперь при включении нескольких виртуальных машин одновременно эти операции выполняются в пакетном режиме, что увеличивает производительность за счет меньшего числа VASA API вызовов.
Поддержка VASA для метода аутентификации CHAP на томах vVols через iSCSI.
3. Улучшения NFS
Для NAS VAAI появилась возможность установки плагинов без перезагрузки.
Раньше клонирование NVDK или LZT диска падало с ошибкой, теперь же для них все отрабатывает отлично.
4. Функция расширения pRDM со службами Microsoft WSFC
Была добавлена поддержка горячего расширения disk/LUN для режима pass-through RDM, использующегося в кластерах Windows Server Failover Clustering (WSFC).
5. Функции NVMeoF
Поддержка Oracle RAC при использовании таргетов NVMeoF
Некоторое время назад мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).
Устройства HCA могут коммуницировать с памятью приложений на сервере напрямую. Грубо говоря, если в обычном режиме (TCP) коммуникация по сети происходит так:
То при наличии на обоих хостах HCA, обмен данными будет происходить вот так:
Очевидно, что такая схема не только снижает нагрузку на CPU систем, но и существенно уменьшает задержки (latency) ввиду обхода некоторых компонентов, для прохождения которых данными требуется время.
Поддержка RDMA появилась еще в VMware vSphere 6.5, когда для сетевых адаптеров PCIe с поддержкой этой технологии появилась возможность обмениваться данными памяти для виртуальных машин напрямую через RDMA API. Эта возможность получила название Paravirtual RDMA (PVRDMA).
Работает она только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Метод коммуникации между виртуальными машинами в таком случае выбирается по следующему сценарию:
Если две машины общаются между собой на одном ESXi, то используется техника memory copy для PVRDMA, что не требует наличия HCA-карточки на хосте, но сама коммуникация между ВМ идет напрямую.
Если машины находятся на хостах с HCA-адаптерами, которые подключены как аплинки к VDS, то коммуникация идет через PVRDMA-канал, минуя обработку на CPU хостов, что существенно повышает быстродействие.
Если в коммуникации есть хоть одна ВМ на хосте, где поддержки RDMA на уровне HCA нет, то коммуникация идет через стандартный TCP-туннель.
Начиная с VMware vSphere 7 Update 1, для PVRDMA была добавлена поддержка оконечных устройств с поддержкой RDMA (Native Endpoints), в частности хранилищ. Это позволяет передать хранилищу основной поток управляющих команд и команд доступа к данным от виртуальных машин напрямую, минуя процессоры серверов и ядро операционной системы. К сожалению для таких коммуникаций пока не поддерживается vMotion, но работа в этом направлении идет.
Чтобы у вас работала технология PVRDMA для Native Endpoints:
ESXi должен поддерживать пространство имен PVRDMA. Это значит, что аппаратная платформа должна гарантировать, что физический сетевой ресурс для виртуальной машины может быть выделен с тем же публичным идентификатором, что и был для нее на другом хосте (например, она поменяла размещение за счет vMotion или холодной миграции). Для этого обработка идентификаторов происходит на сетевых карточках, чтобы не было конфликтов в сети.
Гостевая ОС должна поддерживать RDMA namespaces
на уровне ядра (Linux kernel 5.5 и более поздние).
Виртуальная машина должна иметь версию VM Hardware 18
или более позднюю.
За счет PVRDMA для Native Endpoints виртуальные машины могут быстрее налаживать коммуникацию с хранилищами и снижать задержки в сети, что положительно сказывается на производительности как отдельных приложений и виртуальных машин, так и на работе виртуального датацентра в целом.
На сайте проекта VMware Labs появилась очередная полезная штука - Storage Performance Tester. С помощью данного средства администраторы VMware vSphere могут в один клик проверить производительность хранилищ в плане IOPS, Latency и циклов CPU на одну операцию ввода-вывода для серверов VMware ESXi.
Эта утилита автоматизирует все шаги, которые необходимо предпринять для тестирования, включая развертывание виртуальных машин, запуск нагрузки по вводу-выводу, а также анализ производительности хранилища. Метрики, полученные в результате тестирования, визуализируются на графиках. Единственная вещь, которую вам нужно сделать - это выполнить соответствующую команду и ждать сгенерированного отчета о производительности хоста ESXi.
Средство создано как для администраторов платформы vSphere, так и для разработчиков, которым требуется решать проблемы производительности в виртуальной инфраструктуре. Также Storage Performance Tester удобно использовать для получения максимальных параметров производительности аппаратного обеспечения, а также программных компонентов (драйверы, настройки vSphere и vSAN).
Для запуска тестовой среды вам понадобятся:
python3
sshpass
2 ГБ свободного места
Linux-окружения (с версией ядра не менее 2.6.31)
Вот небольшое обзорное видео, где можно посмотреть всю процедуру запуска утилиты и, собственно, сам отчет с результатами тестирования:
Скачать Storage Performance Tester можно по этой ссылке.
Не так давно мы писали о том, что в последней версии VMware vSphere 7 Update 1 технология vMotion стала еще быстрее и теперь обеспечивает нужды горячей миграции даже для самых тяжелых виртуальных машин.
Напомним, что VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.
Интересны некоторые моменты. Например, в vSphere 6.7 используется технология отслеживания изменений CPU во время миграции stop-based trace, которая "подмораживает" все CPU, а в vSphere 7 U1 уже подмораживается только один процессор (техника loose page-trace Install):
Также vSphere 7.0 U1 передает compacted bitmap памяти вместо полного, что уменьшает время переключения на ВМ другого хоста:
Интересно уменьшение влияния миграции тяжелой БД Oracle на производительность - улучшение составило 19 раз!
Время миграции - до 50% меньше:
Ну и вообще в документе очень много всего интересного для интересующихся. Читайте здесь.
Недавно на сайте проекта VMware Labs появилось обновление этой платформы до версии 1.1. Эту версию нужно обязательно ставить заново, потому что обновление с версии 1.0 не поддерживется.
Давайте посмотрим, что там появилось нового:
Исправлена критическая ошибка, вызывавшая розовый экран смерти (PSOD) при добавлении к коммутатору VDS (см. тут)
Поддержка аппаратной платформы Arm N1 SDP
Поддержка виртуальных машин на процессорах Neoverse N1 CPU
Улучшения стабильности работы на платформах LS1046A и LX2160A
Исправления ошибок для отображения некорректного использования CPU на vCenter/DRS
Исправление ошибки с аварийным завершением виртуальной машины при полной заполненности хранилища
Исправление ошибки с поддержка устройств non-coherent DMA
Теперь можно ставить гипервизор имея в распоряжении 4% от 4 ГБ памяти вместо 3.125 (критично для некоторых аппаратных платформ)
Улучшения работы с последовательным портом
Обновление документации (больше информации об iSCSI, документы по платформам LS1046ARDB и Arm N1SDP, обновлен список поддерживаемых гостевых ОС)
Скачать VMware ESXi Arm Edition 1.1 можно по этой ссылке. Ну и бонусом несколько видео от Вильяма Лама по использованию этой платформы:
Это гостевой пост нашего спонсора - компании ИТ-ГРАД, предоставляющей услугу аренды виртуальных машин из облака. Сегодня мы поговорим о vRealize Automation. Статья ориентирована на пользователей, которые ранее не сталкивались с этим решением, поэтому под катом мы познакомим вас с его функциями и поделимся сценариями использования...
Многие из вас знакомы с одноплатной ARM-архитектурой компьютеров Raspberry Pi, которые позволяют модульно собирать очень крутые штуки для целей тестирования и обучения. Недавно компания VMware выкатила технологическое превью гипервизора ESXi для процессоров ARM (он же ESXi-Arm), которое доступно на сайте VMware Labs.
Конечно же, многие пользователи бросились устанавливать его на компьютеры Raspberry Pi, которые в большом количестве есть у энтузиастов. Оказалось, что поставить туда ESXi весьма простая задача, особенно, если речь идет о Raspberry Pi 4.
2x USB drive (один для записи гипервизора, а второй как installation media)
Кабель USB-C (питание)
Micro HDMI для монитора
Сначала лучше прочитать официальный гайд по продукту, который есть на странице ESXi-Arm сайта VMware Labs. Для старых модификаций Raspberry Pi могут быть нюансы, но с новыми для Windows порядок примерно такой:
Копируем содержимое загрузочной директории на SD-карту
Копируем содержимое архива RPi4_UEFI_Firmware_v1.20.zip с перезаписью поверх существующего содержимого на SD-карту
Если у вас Raspberry Pi на 4 ГБ, открывайте config.txt и добавляйте следующую строчку в конец файла без пробелов: gpu_mem=16
Настраиваем UEFI:
Вставляем SD-карту в Raspberry Pi
Подключаем USB-клавиатуру и монитор по HDMI
Подключаем питание через USB-C
Нажимаем ESC до того, как покажется UEFI menu
Идем в раздел:
Device Manager > Raspberry Pi Configuration > Advanced Configuration
Подсвечиваем опцию Limit RAM to 3GB
Нажимаем Enter и стрелками на клавиатуре выставляем значение DISABLED
По F10 сохраняем конфигурацию
Нажимаем ESC, чтобы выйти на домашнюю страницу
Идем к Continue и нажимаем Enter
Тепреь загружаем установочный образ VMware-VMvisor-Installer-7.0.0-16966451.aarch64.iso по этой ссылке.
Теперь из ISO-образа с помощью UNetbootin надо создать загрузочную флешку:
Далее:
Вставляем установщик на USB-флешке в Raspberry Pi
Нажимаем ESC до того, как покажется UEFI menu
Выбираем USB-флешку первой в порядке загрузки
После начала загрузки ESXi:
Быстро нажимаем SHIFT+O (это буква)
Внизу экрана вбиваем autoPartitionOSDataSize=8192 (это ограничит установку ESXi 8 ГБ, остальное пространство можно будет отдать под датастор для виртуальных машин)
При установке ESXi убедитесь, что указано корректное устройство для установки гипервизора
Вставляем сетевой кабель и убираем флешку
Далее после включения нужно опять пойти в Boot Maintenance Manager > Boot Options > Change Boot Order и выбрать там флешку, куда вы установили ESXi:
После этого ваш ESXi загрузится и получит IP-адрес от DHCP, который лучше заменить на статический. После этого вы можете соединиться с хостом через веб-интерфейс и увидеть, что для остатков пространства на флешке был создан датастор для виртуальных машин.
В начале октября этого года прошла конференция VMworld 2020, которую компания VMware впервые провела исключительно в онлайн-формате. Там было сделано много интересных анонсов, главные из которых - это развитие экосистемы поддержки контейнеризованных приложений и расширение продуктовой линейки для автоматизации облачных инфраструктур.
Сегодня мы поговорим о второй части - решении VMware vRealize AI Cloud, которое предназначено для автоматического повышения эффективности использования хранилищ в рамках концепции самооптимизирующегося датацентра.
Эту концепцию вендоры различных ИТ-платформ продвигают уже давно. Ее суть заключается в том, что решения в рамках датацентра будущего (как программные, так и аппаратные) должны самостоятельно отслеживать изменяющиеся метрики среды, в которой они работают, после чего автоматически вносить коррективы в конфигурации для максимально эффективного функционирования инфраструктуры в целом.
Еще одним трендом VMware считает развитие гибридных инфраструктур, которые будут строить крупные компании. В гибридной среде важна унификация процедур управления и технических инструментов, над чем VMware работает уже давно (например, в этой парадигме построено решение Cloud Director 10.2).
Так вот, в гибридной среде у каждого онпремизного решения должны быть его облачные аналоги, но должны быть и чисто облачные инструменты, которые как раз делают датацентр самооптимизирующимся, поскольку за это отвечает вендор платформы. Одним из таких инструментов и стало решение vRealize AI Cloud:
vRealize AI Cloud поставляется вместе с решением vRealize Operations Cloud в рамках подписки vRealize Cloud Universal. За счет использования алгоритмов машинного обучения этот продукт позволяет адаптироваться к изменяющимся условиям в характере нагрузок и проводить постоянную оптимизацию использования хранилищ (а именно улучшая конкретные KPI, вроде пропускной способности или latency).
Сейчас эта технология работает только с хранилищами vSAN, но потенциально нет никаких препятствий для VMware открыть ее и для других облачных хранилищ.
Как видно из картинки выше, vRealize AI Cloud генерирует и применяет настройки для оптимизации работы с хранилищами, а также дает администратору инструменты для отслеживания производимых изменений и средства мониторинга измеренных количественных улучшений.
Консоль vRealize AI Cloud предлагает администратору решения 4 блоков задач:
Оптимизация производительности в кластере
Оптимизация емкости хранилищ
Решение проблем разного характера, в зависимости от типа объекта
Анализ конфигураций объектов и управление ими
Если перейти на уровень виртуальных датацентров, администратор видит те из них, где оптимизация кластеров уже включена (зелено-синий цвет), и те, где выключена, причем для обоих вариантов показано, на сколько процентов можно улучшить количественные метрики:
Можно провалиться на уровень кластера (выбрав соответствующую точку в периметре) и увидеть определенные хосты ESXi, где могут быть проведены оптимизации:
В частности мы видим в реальном времени поток оптимизаций (верхняя строчка), а также основные параметры производительности справа - latency и пропускную способность:
Раскрыв уровень оптимизаций, можно увидеть, какие конкретно настройки и в какое время были изменены. В данном случае был уменьшен размер кэша, поскольку AI Cloud предположил, что это улучшит write latency на 25%:
Конечно же, предположения могут не оправдаться, и тогда AI Cloud откатит настройку, чтобы убедиться, что хуже KPI не стали.
В потоке действий AI Cloud мы четко видим таймлайн изменений и детальные графики производительности на уровне каждого из выбранных хостов:
Если AI Cloud не включен в кластере, то будет рассчитан примерный потенциал оптимизаций, который, на самом деле, представляет собой довольно серьезные цифры, поэтому вполне имеет смысл хотя бы включить и попробовать AI Cloud в деле:
Когда вы включаете этот движок, вы можете выбрать степень агрессивности работы алгоритма оптимизаций:
Консервативный режим всегда оставляет запас по производительности и емкости при выполнении рекомендаций по оптимизации, а агрессивный - действует весьма смело. Как всегда, начинать нужно с консервативного режима и потом потихоньку увеличивать степень. После включения механизма AI Cloud начнется процесс обучения системы паттернам нагрузок, только после чего уже начнется генерация и применение рекомендаций.
В среднем, по тестам VMware, оптимизации хранилищ vSAN могут достигать 60% за счет использования движка AI Cloud. Например, по тестам Rackspace в 4-узловом кластере хранилищ улучшения полосы пропускания на запись (write-throughpu) составили 18%, а уменьшение задержек находилось на уровне 40%-84%.
Также AI Cloud тесно интегрирован с политиками хранилищ SPBM (Storage Policy Based Management). Настройки этих политик также влияют на производительность - например, можно отключить дедупликацию, и это существенно улучшит производительность хоста за счет уменьшения нагрузки на CPU и хранилища:
В целом, решение vRealize AI Cloud - это шаг вперед в реализации концепции самооптимизирующихся датацентров в разрезе хранилищ. Будем надеяться, что решение уже скоро будет доступно в облачных инфраструктурах сервис-провайдеров VMware Cloud.
Также на конференции VMworld Online 2020 компания VMware показала, как именно будет выглядеть решение vRealize AI Cloud:
Суть ее заключается в том, что при удалении снапшота ВМ, по завершении ее резервного копирования, она замирает примерно на 30 секунд, не принимая никакой ввод-вывод. Происходит это на некоторых NFS-хранилищах, в частности HPE SimpliVity. В итоге - приложения, чувствительные ко времени, работают плохо, ну и в целом такое поведение не очень приятно для производственных систем.
Проблема проявилась при использовании платформы VMware vSphere 6.7, текущей версии Veeam Backup and Replication и хранилища HPE SimpliVity, которое поддерживает презентацию томов только в режиме NFS v3.
При этом в такой же комбинации продуктов, но на блочных хранилищах удаление снапшота занимало 1-2 секунды.
После общения с поддержкой нашлись следующие workaround'ы, которые не подошли:
Использовать NFS v4 вместо v3 (доступно не на всех хранилищах)
Использовать другой транспорт (transport mode), например, Direct access или NBD (Network Block Device). Но Direct access доступен не всегда, а NBD - медленный режим.
Можно использовать режим hot-add с виртуальным модулем backup appliance, но тогда он должен быть на каждом хосте (см. KB 201095).
Можно отключить синхронизацию времени с хостом для ВМ с приложениями, которые страдают из-за замирания времени в гостевой ОС. Об этом можно почитать в KB 1189. Но это так себе решение.
На текущий момент получается, что это проблема именно VMware ESXi, см. статью KB 2010953. Также она описана и в базе знаний Veeam - KB 1681 (там же указаны и обходные пути). Таким образом, выходит, что в некоторых случаях ни одно из решений не подходит на 100%.
Недавно мы писали об анонсе Project Monterey на прошедшей конференции VMworld Online 2020. Это переработка архитектуры VCF таким образом, чтобы появилась родная интеграция новых аппаратных возможностей и программных компонентов. Например, новая аппаратная технология SmartNIC позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF. Но на этом новости не закончились.
На днях VMware выпустила еще одно важное средство на сайте проекта VMware Labs - модуль ESXi-Arm. Это, по-сути, издание VMware ESXi для компьютеров с 64-битными процессорами архитектуры ARM. Пока, конечно же, в режиме технологического превью, созданного в целях сбора обратной связи от пользователей.
История проекта такова - группа инженеров внутри VMware решила портировать ESXi с архитектуры x86 на ARM, после чего энтузиасты внутри компании поддерживали согласование нововведений в гипервизоре в рамках платформы x86 с версией для ARM. Теперь эта версия ESXi считается доведенной до ума, и она была выпущена публично:
На данный момент в экспериментальном режиме было протестировано следующее оборудование:
Вы также можете управлять таким ESXi на архитектуре ARM с помощью обычного VMware vCenter 7.0 или более поздней версии.
Скачать VMware ESXi для ARM в виде загрузочного ISO-образа можно по этой ссылке. Документация доступна там же, правильный документ надо выбрать из комбобокса:
Также вот небольшое обзорное видео об установке ESXi на компьютер Raspberry Pi от Вильяма Лама:
Как вы все знаете, на прошлой неделе прошла главная конференция по виртуализации этого странного года - VMworld 2020 Online. Несмотря на то, что она прошла онлайн, было сделано немало интересных объявлений, а перед самой конференцией были анонсированы главные обновления продуктовой линейки. Одним из них был скорый выпуск новой версии платформы VMware vSphere 7 Update 1, который и состоялся:
На днях также появилась возможность скачать новые версии нескольких продуктов, помимо vSphere 7 U1. Давайте посмотрим, какие именно решения были выпущены:
На сайте проекта VMware Labs появилось очередное бесплатное средство для администраторов VMware vSphere - SQL30. Эта штука представляет собой ORM-обертку для легковесной БД SQLITE под ESXi.
Python нативно поддерживает взаимодействие с SQLITE за счет модуля "sqlite" (или sqlite3 в python3). Ну а решение SQLAlchemy - это популярная ORM, используемая для взаимодействия с базами данных sqlite из Python. Однако это решение не работает на ESXi, так как многие его пакеты имеют зависимости от других пакетов, которые не могут быть установлены на ESXi.
Решение SQL30 как замена SQLAlchemy - весьма легковесно и написано только с использованием нативных конструкций Python, а также не имеет никаких внешних зависимостей, поэтому работает на ESXi 6.5 и более поздних версиях.
SQL30 вам пригодится для:
Возможности использования разработчиками интерфейсов Python на платформах с ограниченным применением, таких как ESXi
Предоставления разработчикам приложений доступа к базе данных без необходимости знания SQL
На VMware ESXi 6.5 будет использоваться версия Python 3.5, что ниже актуальной версии 3.6, но все равно лучше чем ничего.
Скачать SQL30 можно тут. Инструкции по установки приведены вот здесь.
Как вы знаете, на прошлой неделе компания VMware провела первую в истории онлайн-конференцию VMworld 2020 Online. Основные анонсы новых версий продуктов былисделаны еще до конференции, а VMware рассказывала, в основном, о новых технологиях и будущих продуктах для виртуального датацентра.
Одним из таких анонсов стала новость о разработке решения Project Monterey.
По заявлению VMware, Monterey - это продолжение развития технологии Project Pacific для контейнеров на базе виртуальной инфраструктуры, только с аппаратной точки зрения для инфраструктуры VMware Cloud Foundaton (VCF).
Потребности современных приложений, многие из которых работают в контейнерах, рождают повышенные требования к оборудованию, а особенно к ресурсам процессора. Также с каждым годом все больше ужесточаются требования к безопасности и изоляции систем.
Поэтому вендоры аппаратного обеспечения пытаются сделать высвобождение некоторых функций CPU, передав их соответствующим компонентам сервера (модуль vGPU, сетевая карта с поддержкой offload-функций и т.п.), максимально изолировав их в рамках необходимостей. Но вся эта новая аппаратная архитектура не будет хорошо работать без изменений в программной платформе.
Project Monterey - это и есть переработка архитектуры VCF таким образом, чтобы появилась родная интеграция новых аппаратных возможностей и программных компонентов. Например, новая аппаратная технология SmartNIC позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF.
Также за счет технологии SmartNIC инфраструктура VCF будет поддерживать операционные системы и приложения, исполняемые на "голом железе" (то есть без гипервизора). В данном решении будет три основных момента:
Поддержка перенесения сложных сетевых функций на аппаратный уровень, что увеличит пропускную способность и уменьшит задержки (latency).
Унифицированные операции для всех приложений, включая bare-metal операционные системы.
Модель безопасности Zero-trust security - обеспечение изоляции приложений без падения производительности.
Вот так будет выглядеть сетевой адаптер сервера, поставляемый в партнерстве с вендорами оборудования:
Таким образом, это сетевая карта с обычным CPU, который занимается решением задач производительности и безопасности. Она будет состоять из следующих компонентов:
Стандартный процессор общего назначения (general-purpose CPU) - позволяет исполнять часть кода прямо на сетевом адаптере (сервисы сети и хранилищ), что существенно увеличивает производительность (за счет уменьшения пути для операций ввода-вывода) и экономии циклов CPU сервера.
Унифицированный процесс управления CPU сетевой карты, который предоставляет отдельный рабочий процесс, доступный из Lifecycle Manager.
Возможность предоставления виртуальных устройств - SmartNIC может шарить на PCI-шине несколько виртуальных устройств, которые будут показываться гостевым ОС отдельными карточками.
Часть стандартной функциональности сервера и его CPU теперь переезжает на сетевую карту SmartNIC в рамках инфраструктуры VCF:
Тут есть следующие интересные моменты:
ESXi on SmartNIC - да, теперь гипервизор будет работать на сетевой карте! Для этого VMware и делала порт ESXi для ARM-процессоров (помните анонсы 2018 года?), которые в основном и будут использоваться для устройств SmartNIC.
2 экземпляра ESXi на одном сервере - один на обычном CPU, а второй - на SmartNIC. Управлять ими можно как единым функциональным блоком, так и каждым гипервизором по отдельности.
Сервисы сети и доступа к хранилищам - за счет этих сервисов повышается быстродействие и разгружается основной процессор сервера.
SmartNIC ESXi теперь будет уметь управлять хостом ESXi, что упростит процедуры обслуживания жизненного цикла с помощью LCM.
Двойной контроль - если основной гипервизор скомпрометирован, то отдельный SmartNIC ESXi будет продолжать предоставлять сервисы защиты, что улучшает защищенность инфраструктуры.
Управление bare-metal операционными системами теперь будет происходить со стороны карточек SmartNIC, которые существенно упростят управление единой инфраструктурой датацентра.
Теперь архитектура VCF будет позволять шарить ресурсы SmartNIC и для сервисов на других серверах. Это открывает очень широкие возможности по построению кластеров, где ресурсы приложениям доступны из общего пула:
Все это будет поддерживать кластеры Kubernetes и решение VCF with Tanzu, что расширит сферу применения SmartNIC для крупных инфраструктур, где ресурсы и сервисы необходимо выделять по требованию, а не планировать конфигурации серверов под конкретные приложения. Конечно же, все будет управляться не только через консоли, но и через API.
В итоге, вариантами использования SmartNIC станут:
Сетевая производительность (передача сетевых функций на уровень адаптера) и безопасность (например, отдельный L4-7 фаервол на уровне сетевой карты).
Улучшение сервисов датацентра - например, с помощью Project Monterey можно будет использовать offloaded-сервисы доступа к хранилищам, сжатие и т.п., что повысит производительность без создания единого домена отказа и падения производительности. Это повысит гибкость использования решения и даст возможность применения таких сервисов, как dynamic storage profiles (для управления емкостями и операциями ввода-вывода, IOPS) и удаленный доступ к хранилищам по требованию.
Управление системами bare-metal - для тех, кто мечтал о единой консоли vSphere для физических и виртуальных систем.
Также все это сможет работать в гибридных облаках, как работают сейчас инфраструктуры VCF.
На данный момент главными аппаратными партнерами VMware в части технологии SmartNIC являются компании NVIDIA, Pensando и Intel. С точки зрения производителей серверов, первыми партнерами станут Dell Technologies, HPE и Lenovo. Этот список будет со временем расширен.
На прошедшем VMworld 2020 Online проекту Monterey были посвящены следующие сессии, которые вы можете найти тут:
Многие из вас знают, что компания VMware с каждым новым релизом мажорной версии платформы vSphere улучшает техники горячей миграции виртуальных машин vMotion. Последнее обновление VMware vSphere 7 Update 1 - не исключение, там было сделано много для того, чтобы технология vMotion работала еще быстрее и обеспечивала нужды горячей миграции даже для самых тяжелых виртуальных машин.
Ранее vMotion могла не пройти для больших ВМ, которые имели более 64 vCPU и 512 ГБ памяти (они же Monster VMs). В документе "vMotion Innovations in vSphere 7.0 U1" можно найти конкретное описание улучшений. Давайте посмотрим на них вкратце.
Прежде всего, VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.
В документе выше для примера делается миграция vMotion сервера БД Oracle, запущенного в виртуальной машине с 72-vCPU / 1 TБ памяти на борту. На картинке ниже показано число тразакций в секунду с шагом как раз в секунду - до, во время и после vMotion (тест HammerDB):
Основные выводы теста, проведенного для такой нагрузки:
Общее время миграции уменьшилось более чем в 2 раза (с 271 секунды до 120 секунд)
Итоговое время для установления трассировки уменьшилось с 86 секунд до 7.5 секунд (снизилось в 11 раз)
Общее проседание пропускной способности во время миграции - на 50% для vSphere 6.7 и всего лишь 5% для vSphere 7.0 Update 1
Ответ Oracle во время переключения в среднем стал менее одной секунды, а ранее составлял более 6 секунд
Второй тест проводили для миграции vMotion сервера БД Oracle в виртуальной машине с 12 vCPU / 64 ГБ памяти для vSphere 6.7 и vSphere 7.0 U1. На картинке ниже показано число транзакций в секунду с шагом в полсекунды - до, во время и после vMotion (тест HammerDB):
Основные результаты теста:
Общее время горячей миграции сократилось с 23 секунд в vSphere 6.7 до 11 секунд в vSphere 7.0 U1 (уменьшение в 2 раза)
Итоговое время для установления трассировки уменьшилось с 2.8 секунд до 0.4 секунд (снизилось в 7 раз)
Увеличение полосы пропускания где-то на 45% (около 3480 транзакций в секунду, по сравнению с 2403 транзакции в секунду)
Как многие из вас знают, в последние пару лет очень сильно увеличилось число и масштаб атак, связанных с уязвимостями в аппаратном обеспечении. Наибольшую известность получили уязвимости Meltdown и Spectre, которые были обнаружены в процессорах Intel.
Самый неприятный момент, связанный с подобного рода уязвимостями - это то, что поскольку они связаны с аппаратной частью процессоров на самом низком уровне, то, во-первых, ее сложнее исправить и доставить конечным пользователям, а, во-вторых, неправильное обновление, закрывающее эти дырки, может вызвать различные побочные эффекты.
Так, например, было с производительностью серверов VMware ESXi, когда производители ОС совместно с Intel выпустили соответствующие обновления, а VMware выпустила закрывающий уязвимость патч. Сам патч тогда пришлось отозвать и ждать нового, а ведь это потраченного время администраторов, время пользователей и время, в течение которого существует угроза безопасности инфраструктуры предприятия.
Поэтому производители процессоров, совместно с вендорами платформ виртуализации, сейчас уделяют этому моменту особое внимание. Конечно же, в этом направлении работает и AMD, которая активно внедряет следующие технологии:
Secure Encrypted Virtualization (SEV) - первая версия технологии, анонсированная в 2016 году. Она позволяет изолировать виртуальные машины от гипервизора, со стороны которого может быть угроза безопасности при его компрометации. Если гипервизор попытается считать память гостевой ОС, он увидит только зашифрованные данные.
SEV-ES (Encrypted State) - вторая версия технологии, представленная в 2017 году. Она дополняет защиту памяти гостевой ОС шифрованием регистров CPU гостевой ОС. Таким образом, гипервизор не может видеть регистры процессора, активно используемые виртуальной машиной.
SEV-SNP (Secure Nested Paging) - следующее поколение технологии, которое было анонсировано в этом году. Оно добавляет функции аппаратной безопасности для контроля над интеграцией памяти гостевых ОС, что защищает от таких атак, как data replay, memory re-mapping и других (подробнее тут и на картинке ниже).
В недавнем обновлении платформы виртуализации VMware vSphere 7 Update 1 появилась поддержка технологии SEV-ES (Encrypted State), которая должна еще больше защитить от потенциальных уязвимостей, связанных с доступом к данным в рамках процессора. Работает это на процессорах AMD EPYX 7xx2 CPU
или более поздних и требует VM Virtual Hardware версии 18, которое появилось в Update 1.
Надо начать с того, что у VMware уже есть защита памяти и данных гостевой ОС на уровне платформы (а в самих ОС тоже есть средства защиты памяти и процессора), но, само собой, эти механизмы на надежны на 100%, потому что ключевой компонент платформы - гипервизор, обладает очень широкими полномочиями (в виду необходимости), и при его компрометации ничего особо не поможет. Поэтому самое разумное - это поддержать подход изоляции ВМ от гипервизора на аппаратном уровне. Он, кстати, называется Trusted Execution Environment (TEE).
Подход AMD заключается в том, что они добавляют специальный Secure Processor, маленький сопроцессор, интегрированный в основной чип CPU, который является основой безопасности и поддерживает операции шифрования, в том числе и для SEV-ES.
Первое поколение EPYC CPU поддерживало хранение только 15 ключей шифрования, но следующее поколение уже поддерживает более 500. Один из таких ключей используется для гипервизора, а остальные - для гостевых систем.
Для чего вообще нужно защищать регистры процессора гостевых систем? Очень просто - когда виртуальная машина переключает контекст исполнения (меняет процессор), гипервизор получает ресурсы CPU обратно, вместе с содержимым регистров. А в них может храниться много "полезного" для злоумышленника - например, ключи для расшифровки дисков гостевой системы.
Работает механизм ключей так - гостевая ОС запрашивает у процессора с поддержкой SEV ключ шифрования для памяти, а SEV-ES расширяет его и на регистры процессора тоже, после чего гостевая ОС может безопасно использовать память и регистры, не беспокоясь что гипервизор или другие ВМ, изолированные в рамках процессов VMX, считают их содержимое. Очевидно, что гостевая ОС тоже должна поддерживать реализацию SEV-ES (поэтому надо читать соответствующую документацию к ним, чтобы узнать о поддержке).
Самым большим минусом использования технологии SEV-ES является невозможность поддержки таких техник, как vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance и горячих клонов - ведь для их реализации гипервизор должен иметь прямой доступ к памяти гостевых систем. В то же время надо отметить, что это не ограничение от AMD, которая заявляет, что SEV поддерживает live migration и прочее, а ограничение реализации от VMware.
В большинстве производственных окружений невозможность применения этих технологий будет ограничивать использование SEV-ES только системами, требующих наивысшего уровня защищенности.
С другой стороны, например, недавно вышедшее решение vSphere with Tanzu не использует vMotion для машин с контейнерами виртуализованных приложений - они просто выключаются на одном хосте и включаются на другом, то есть здесь есть перспективы применения SEV-ES.
Также использованием технологии SEV-ES можно управлять в пакетном режиме сразу для нескольких тысяч виртуальных машин через интерфейс PowerCLI, что особенно актуально для контейнеров Tanzu. На данный момент VMware еще не опубликовала официальный референс по командлетам для SEV-ES, ждем.
Ну и недавно VMware выпустила интересное видео, рассказывающее о первой имплементации технологии SEV-ES в платформе VMware vSphere 7 Update 1:
Как итог можно отметить, что пока такие технологии, как Secure Encrypted Virtualization имеют достаточно узкое применение ввиду их ограничений. Однако это лишь первые шаги, которые производители процессоров делают совместно с вендорами платформ виртуализации, чтобы защитить ИТ-среду предприятия он новой волны атак на программно-аппаратную инфраструктуру датацентра. Дальше все это будет развиваться, будет и поддержка AMD SEV-SNP, что уже будет существенно уменьшать поверхность возможных атак.
Одной из новых возможностей VMware vSphere 7 U1 стала служба vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter.
Как вы знаете, кластер HA/DRS очень зависит от постоянной доступности сервисов vCenter, который является критическим звеном виртуальной инфраструктуры. Поэтому для него организовывают такие сервисы, как vCenter Server High Availability (VCHA), но и они не идеальны. Также проблема наблюдается при масштабировании кластеров в больших окружениях, которые объединяют онпремизные и облачные площадки, где масштабируемость vCenter является серьезной проблемой.
Учитывая это, VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:
Таких виртуальных машин три в кластере, где 3 или более хостов, и две, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.
Три этих виртуальных машин следят друг за другом и оповещают об этом кластерные службы vCenter:
Это самокорректирующийся механизм, что значит, что если одна из агентских машин становится недоступной или выключенной, то службы vCLS пытаются самостоятельно наладить работу ВМ или включить ее.
Есть 3 состояния служб vCLS:
Healthy – как минимум 1 агентская ВМ работает в кластере, чтобы обеспечить доступность кластера развертываются 3 ВМ для кворума.
Degraded – как минимум одна агентская машина недоступна, но DRS продолжает функционировать и исполнять свою логику. Такое может, например, произойти при передеплое служебных машин vCLS или после какого-то события, повлиявшего на их "включенность".
Unhealthy – логика DRS не выполняется (балансировка или размещение ВМ), так как vCLS control-plane недоступна (то есть ни одной агентской ВМ не работает).
Легковесные машины-агенты исполняются на хостах ESXi и лежат на общих хранилищах, если общие хранилища недоступны - то на локальных дисках. Если вы развернули общие хранилища после того, как собрали кластер DRS/HA (например, развернули vSAN), то рекомендуется перенести агентские ВМ с локальных хранилищ на общие.
Сама гостевая ОС агентских ВМ очень легковесная, используется Photon OS следующей конфигурации:
Диск в 2 ГБ - это тонкий диск, растущий по мере наполнения данными (thin provisioned). Эти машины не имеют своего нетворка, а также не видны в представлении Hosts and Clusters в клиенте vSphere.
Агентские ВМ можно увидеть в представлении VMs and Templates где есть папка vCLS:
Обратите внимание, написано, что для агентских ВМ управление питанием производится со стороны служб vCLS. Если вы попытаетесь выключить эти ВМ, то будет показано следующее предупреждение:
При переводе кластера в режим обслуживания vCLS сам заботится о миграции агентских ВМ с обслуживаемых серверов и возвращении их обратно. Для пользователя это происходит прозрачно. И, конечно же, лучше не выключать эти ВМ вручную и не переименовывать папки с ними.
Жизненный цикл агентских ВМ обслуживается со стороны vSphere ESX Agent Manager (EAM).
EAM отвечает за развертывание и включение агентских ВМ, а также их пересоздание, если с ними что-то произошло. В анимации ниже показано, как EAM восстанавливает ВМ, если пользователь выключил и/или удалил ее:
Важный момент для разработчиков сценариев PowerCLI - это необходимость обрабатывать такие ВМ, чтобы случайно не удалить их. Например, ваш скрипт ищет неиспользуемые и забытые ВМ, а также изолированные - он может по ошибке принять машины vCLS за таковые и удалить, поэтому их надо исключать в самом сценарии.
В интерфейсе vSphere Client список агентских ВМ можно вывести в разделе "Administration > vCenter Server Extensions > vSphere ESX Agent Manager".
У агентских ВМ есть свойства, по которым разработчик может понять, что это они. В частности:
ManagedByInfo
extensionKey == "com.vmware.vim.eam"
type == "cluster-agent"
ExtraConfig keys
"eam.agent.ovfPackageUrl"
"eam.agent.agencyMoId"
"eam.agent.agentMoId"
Основное свойство, по которому можно идентифицировать агентскую ВМ, это HDCS.agent, установленное в значение "true". В Managed Object Browser (MOB) выглядит это так:
Ну и напоследок - небольшое демо технологии vSphere Clustering Service:
Как вы знаете, у компании VMware есть клиент для управления отдельными хостами VMware ESXi, который называется VMware ESXi Embedded Host Client. Последний раз обновлялся он в феврале прошлого года, и VMware не уделяет ему никакого внимания.
Между тем, VMware рассказала о том, что в ближайшем будущем эта недоработка будет исправлена. Дело в том, что интерфейс существующего хост-клиента построен на базе фреймворка Angular JS web framework, последний стабильный релиз которого 1.7 вошел в фазу long term support 30 июня 2018 года. Начиная с 1 января 2022 года, Angular JS больше не будет поддерживаться со стороны Google.
Последующие релизы фреймворка (Angular 4 и более поздние) не будут совместимы с Angular JS. Соответственно, VMware пора уходить с технологии, которая скоро устареет. Поэтому Host Client переедет с технологии Angular JS на последнюю версию Angular web framework (сейчас это Angular 9).
Вместе с этим произойдет и удаление компонентов, которые зависят от Angular JS, а также апдейт основного графического фреймворка Clarity на третью версию.
Собственно, это та причина, по которой VMware не обновляет текущий ESXi Host Client. Этот клиент больше не будет получать новых возможностей, но будет получать некоторые текущие обновления.
А вот новый клиент выйдет уже как Single host managing UI (он же ESXi UI) во второй половине 2021 года.
Для старого клиента будут предоставляться только следующие обновления:
Только доступность самых критичных блоков функциональности и обеспечение апдейтов безопасности
Поддержка текущих рабочих процессов, для которых нет альтернативы
Решение проблем с производительностью
Все прочие проблемы, которые могут привести к оттоку пользователей клиента
Новый ESXi UI будет являться частью ESXi Client и будет построен на базе Clarity 3 в его составе. Соответственно все процессы управления отдельным хостом ESXi будут аналогично таковым в рамках кластера под управлением vCenter.
VMware выпустит этот клиент как только сможет реализовать там все основные рабочие процессы и операции жизненного цикла текущего Host Client, включая развертывание ВМ, конфигурацию, мониторинг, решение проблем и обновление. Это займет время, поэтому нам и ждать полноценной версии где-то год.
Но первую версию нового клиента с базовой функциональностью нам обещают уже в первом квартале следующего года.
Основной фишкой первого пакета обновления седьмой версии vSphere стал, конечно же, финальный выпуск платформы VMware vSphere with VMware Tanzu, объединяющей миры виртуальных машин и контейнеризованных приложений в рамках инфраструктуры предприятия.
Вот небольшой обзор платформы VMware vSphere with Tanzu, о первых объявлениях компонентов которой мы уже писали тут и тут (а о текущей версии рассказано в блоге VMware):
Нововведения vSphere 7 U1 разбиты на 3 блока:
Инфраструктура для разработчиков (контейнеры)
Продолжение масштабирования возможностей платформы
Упрощение операций администраторов
Итак, давайте посмотрим, что нового в VMware vSphere 7 Update 1:
1. Инфраструктура для разработчиков
Здесь VMware добавила следующие важные возможности:
Служба Tanzu Kubernetes Grid (TKG) - о ней мы упоминали вот тут. Она позволяет администраторам развертывать Kubernetes-окружения и управлять их составляющими с помощью решения для кластеров Tanzu Kubernetes. Делается это теперь за минуты вместо часов. Также TKG идет в соответствии с политиками upstream Kubernetes, что позволяет сделать процесс миграции максимально бесшовным.
Bring Your Own Networking - пользователи могут выбирать, какой сетевой стек использовать для кластеров Tanzu Kubernetes. Можно использовать традиционную инфраструктуру на базе vSphere Distributed Switch (vDS) для конфигурации, мониторинга и администрирования виртуальных машин и кластеров Kubernetes. Новый Networking for Tanzu Kubernetes clusters позволяет использовать и решения VMware NSX. Также можно использовать Antrea для максимальной производительности внутренней сети для сервисов Tanzu Kubernetes Grid.
Bring Your Own Load Balancer - можно выбирать тип балансировки L4 для кластеров Tanzu Kubernetes. Первым партнером VMware стало решение HAProxy в формате виртуального модуля OVA.
Application-focused management - теперь пользователи могут применять vCenter не только для управления виртуальными машинами, но и для обслуживания, мониторинга и траблшутинга инфраструктуры контейнеров, включая приложения и неймспейсы (подход application focused management).
2. Продолжение масштабирования возможностей платформы
В этой категории нужно отметить следующие возможности:
Monster VMs - для пользователей решений SAP HANA, Epic Operational Databases, InterSystems Cache и IRIS компания VMware позволяет масштабировать виртуальные машин до 24 ТБ памяти и до 768 виртуальных процессоров (vCPU). То есть все ресурсы хоста могут быть предоставлены виртуальной машине, требующей их большое количество. Это было сделано за счет улучшения планировщика ESXi, а также логики ко-шедулинга для больших ВМ.
Cluster scale enhancements - теперь в vSphere 7 U1 кластер может содержать до 96 хостов! Это на 50% больше значения в релизе vSphere 7 (64 штуки):
3. Упрощение операций администраторов
vSphere Lifecycle Manager - теперь vLCM поддерживает и хосты vSAN, и конфигурацию сетевого стека NSX-T. В vSphere 7 Update 1 решение vLCM также мониторит соответствие образов непрерывно, что позволяет вовремя запустить процесс обновления (remediation).
vSphere Ideas - эта функциональность позволяет пользователям запросить возможности vSphere следующих версий прямо из интерфейса vSphere Client, отслеживать статус своих запросов, видеть запросы других пользователей и голосовать за них. Не факт, конечно, что к вам прислушаются, но общую обстановку по тому, что хотят администраторы, вы будете видеть.
vCenter Connect - теперь пользователи могут управлять своими виртуальными ресурсами VMware Cloud on AWS или в других облаках на базе vCenter из единого интерфейса.
Доступность для загрузки VMware vSphere 7 Update 1 ожидается в рамках или после конференции VMworld Online 2020. Следите за нашими обновлениями!
Компания VMware анонсировала новую версию платформы для создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 7.0 Update 1. Напомним, что о прошлой версии vSAN 7 мы писали вот тут.
Данная версия vSAN сфокусирована на функциях по обеспечению эффективности датацентра, которые нацелены на увеличения возврата инвестиций в оборудование и программное обеспечение:
Новые возможности VMware vSAN 7 U1 можно разделить на 3 категории:
Эффективность и производительность
Упрощение операций с инфраструктурой хранения
Интеграция с облачной инфраструктурой
1. Технология HCI Mesh
Главная из новых возможностей - это технология VMware HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):
В такой схеме можно использовать несколько кластеров-клиентов для монтирования датастора, но надо соблюдать правило доступа: не более 64 хостов ESXi к одному датастору, включая хосты серверного кластера.
В такой конфигурации можно делать vMotion виртуальных машин между кластерами vSAN, но хранилище (Storage vMotion) при этом перемещать нельзя.
Также в топологии HCI Mesh можно использовать подход Full Mesh, когда один и тот же кластер выступает и клиентом, и сервером:
Подход Full Mesh позволит вам сбалансировать потребление емкости кластеров хранилищ. При этом есть ограничение: каждый серверный кластер может экспортировать не более 5 датасторов для клиентских кластеров, а каждый клиентский - монтировать не более 5 датасторов серверных кластеров.
Особенности технологии HCI Mesh:
Минимальное число узлов кластера-клиента и кластера-сервера - 2 узла
Технически Compute-only vSAN cluster (без своих датасторов) сейчас работает, но не рекомендуется к использованию и не поддерживается
Поддерживается одновременное использование хранилищ Hybrid (SSD+HDD) и All-Flash одновременно
Небольшой обзор технологии:
2. Поддержка SMB для vSAN Native File Services
VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Таким образом, vSAN теперь поддерживает NFS (версии 3 и 4.1) и SMB.
3. Шифрование vSAN Data-in-Transit Encryption
Теперь в vSAN 7 Update 1 есть возможность шифрования при передаче данных между узлами кластера по протоколу TCP с использованием крипто-модуля FIPS-2. При этом вам не потребуется использовать Key Management Server (KMS).
Также надо отметить, что одновременное использование HCI Mesh и Data-in-Transit Encryption не поддерживается.
4. Техника SSD Secure Erase
В vSAN 7 Update 1 появился надежный способ удаления данных с SSD-дисков. Пока это поддерживается только для оборудования Dell и HPE. Например, это можно будет использовать для готовых серверных узлов vSAN Ready Nodes и комплектов DellEMC VxRail.
5. Общая оптимизация производительности
Как и всегда, VMware проводит работу над улучшением vSAN в контексте производительности. Заявляется, что vSAN 7 Update 1 работает примерно на 30% быстрее при выполнении операций, чем vSAN 6.7 U3 (который до этого был самым производительным).
6. Возможность использования компрессии без дедупликации
Ранее vSAN позволял использовать две этих технологии только вместе, а сейчас можно использовать только сжатие данных, не нагружая вычислительные ресурсы движком дедупликации. Теперь технология работает так:
Дедупликация
На уровне дисковой группы
Работает при дестейджинге данных на capacity tier
Работа с фиксированными блоками 4 КБ
Компрессия
Работает после дедупликации, но до того, как данные дестейджатся
Если блок можно сжать до 2 КБ или менее, то он сжимается
Иначе сохраняется блок 4 КБ
Компрессия работает значительно быстрее дедупликации, поэтому ее отдельно удобно использовать для OLTP-нагрузок.
7. Функция Enhanced durability при выполнении операций обслуживания
Если хост ESXi находится в режиме обслуживания (maintenance mode), то vSAN теперь имеет механизм защиты данных, которые в этот период находятся только в одном экземпляре (у них был задан failures to tolerate равный 1, а а хост перевели в режим обслуживания - и теперь есть только одна активная реплика данных).
В таком случае vSAN понимает, что у вас был FTT=1, и на время обслуживания все операции записи начинает дублировать на выделенный хост для delta writes, чтобы вы не потеряли данные во время отказа хоста с единственной копией данных:
При выходе хоста ESXi из режима обслуживания происходит обновление его данных с временного хранилища, после чего оно высвобождается для дальнейшего использования. Интересно, что для этих целей можно использовать и witness-хост.
Данный механизм можно использовать как для RAID Mirroring, так и для Erasure Coding.
8. Быстрая перезагрузка и ускоренный апгрейд кластеров
Существенное ускорение апгрейда кластеров за счет более быстрой перезагрузки хостов
Метаданные хоста записываются на диск перед перезагрузкой и восстанавливаются в память после загрузки - это ускоряет актуализацию метаданных
Как результат - хосты загружаются до 5 раз быстрее
9. Общий witness-хост для нескольких кластеров
Это очень удобно для ROBO-инсталляций. vSAN 7 Update 1 поддерживает до 64 кластеров в двухузловых конфигурациях с общим witness для ROBO-сценариев (это решения для удаленных офисов и филиалов - Remote or Branch Offices).
10. Оптимизация всегда доступной емкости (Slack Space)
По рекомендациям VMware нужно было всегда держать 25-30% свободной емкости хранилищ в кластере. Это называлось Slack Space. Теперь это называется Reserved Capacity, и ее необходимый объем зависит о числа узлов в кластере (чем меньше узлов - тем меньше емкость), например:
12 node cluster = ~16%
24 node cluster = ~12%
48 node cluster =~ 10%
Эта емкость нужна для:
Операций Resync при изменении политик, ребалансировке, перемещении данных (Operations Reserve)
Активностей Rebuild при отказах хранилищ и хостов (Host Rebuild Reserve)
Надо понимать, что Reserved Capacity предотвращает только развертывание новых виртуальных машин, но не затрагивает ввод-вывод уже имеющихся.
Также Reserved Capacity - это опциональный механизм, который не включен по умолчанию:
Функция vSAN Reserved Capacity не поддерживается для растянутых кластеров и двухузловых конфигураций.
11. Улучшения vSphere Lifecycle Manager (vLCM)
Еще в vSAN 7 поддерживались узлы Dell и HPE для решения vLCM, теперь же к ним добавилось и оборудование Lenovo ReadyNode.
Сам vLCM получил следующие улучшения:
Работа с vSAN Fault Domains, двухузловыми конфигурациями и растянутыми кластерами (Stretched Clusters)
Предпроверки Hardware compatibility pre-checks
Параллельное обновление кластера до 64 хостов
Поддержка окружений с NSX-T 3.1
12. Упрощенная маршрутизация для некоторых топологий
Раньше для топологии vSAN с внешним witness должны были иметь статическую маршрутизацию. Теперь в vSAN 7 Update 1 можно добавить шлюз по умолчанию и не прописывать статические маршруты:
13. Утилита vSAN I/O Insight
С помощью этого средства можно анализировать I/O-паттерны для анализа рабочих нагрузок в кластере. Это утилита, встроенная в vSphere Client, в которой доступен большой набор паттернов метрик и гистограмм для анализа таких вещей, как R/W ratio, Seq/Random ratio, 4K aligned / unaligned ratio, IO size distribution.
Все это позволяет не пользоваться сторонними утилитами для решения узких проблем, а понимать их природу прямо из vSphere Client:
14. Улучшения сервисов для Cloud native applications
Платформа vSAN Data Persistence
- это новый фреймворк для партнеров, который позволяет интегрировать информацию о приложениях для операционных задач через API.
SAN Direct Configuration - это альтернативный способ для прямой интеграции сервисов с хранилищами vSAN.
Улучшения интеграции с vSphere with Tanzu за счет расширений для томов гостевых кластеров TKG, а также получения информации о состоянии томов TKG supervisor и guest.
Доступность для загрузки VMware vSAN 7 Update 1 ожидается в самое ближайшее время, следите за нашими новостями.
Некоторое время назад мы писали о сервисах технической поддержки VMware Skyline (и тут). Напомним, что это проактивная технология VMware для предоставления расширенной технической поддержки некоторым клиентам для продуктов VMware vSphere.
На днях VMware аноснировала новую полезную утилиту Skyline Health Diagnostic Tool, с помощью которой пользователи смогут взаимодействовать с технической поддержкой вендора (GSS) и совмесно работать над возникающими проблемами в техническом ключе.
С помощью утилиты SHD вы сможете более эффективно работать с персоналом GSS, анализируя логи с помощью лог-бандлов для различных решений, и получать рекомендации об оптимизации виртуальной инфраструктуры:
Проще говоря, Skyline Health Diagnostics for vSphere - это утилита самообслуживания, которая позволяет идентифицировать проблемы с помощью лог-бандлов и получить ссылки на помогающие статьи VMware KB. Самое интересное, что утилита Health Diagnostics for vSphere доступна абсолютно бесплатно (за сам сервис Skyline, конечно же, надо платить).
Те из вас, кто использовал Skyline, знают, что есть такое средство Skyline Advisor, которое выполняет схожие (на первый взгляд) функции. Так зачем же нужен Skyline Health Diagnostic Tool?
Во-первых, Skyline Advisor - это облачный веб-сервис, а SHD - полноценный онпремизный тул для заказчиков. Ну а, во-вторых, Skyline Advisor - это тул для проактивной аналитики, а Health Diagnostic Tool сфокусирован на текущем анализе логов и решении проблем.
Управление утилитой Skyline Health Diagnostics происходит через веб-интерфейс виртуального модуля.
SHD выполняет следующие функции:
На базе симптомов какой-либо проблемы представляет ссылку на Knowledge Base (где рассказано о ее исправлении), либо сразу выводит конкретные шаги по устранению трудностей.
Механика самообслуживания ускоряет процесс самостоятельного нахождения причины проблем.
Быстрое приведение инфраструктуры в соответствие с помощью конкретных рекомендаций позволяет оперативно устранить неполадку без нарушения процессов бизнеса.
Установка продукта разбита на 3 простых шага:
Более подробно об установке Health Diagnostic Tool рассказано вот тут, а сам процесс разобран в видео ниже:
Апгрейд виртуального модуля происходит в рамках простого рабочего процесса: надо просто зайти в Settings-> Upgrade & History.
С помощью SHD логи можно анализировать в двух режимах:
Online - можно соединиться с сервером vCenter Server или ESXi и собрать логи. В рамках одной задачи анализа можно обрабатывать до 32 хостов.
Offline - можно руками загрузить логи в формате .TGZ или zip-файла (когда отчеты сгенерируются, они будут доступны для скачивания.
Загрузить VMware Skyline Health Diagnostic Tool можно по этой ссылке. Документация доступна тут.
Коллега с virten.net написал замечательную статью об использовании сетевых адаптеров USB на хостах VMware ESXi, основные моменты которой мы приведем ниже.
Напомним, что подключить сетевые адаптеры USB на хостах ESXi можно с помощью драйвера USB Network Native Driver for ESXi, о котором мы не так давно писали вот тут. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.
Еще один вариант использования таких адаптеров - когда у вас (например, на тестовом сервере) есть всего один гигабитный порт, а вам нужно тестировать технологии и продукты, где нужно несколько высокоскоростных соединений.
Итак, после того, как вы скачаете драйвер, его установка делается одной командой:
С помощью PowerShell можно создать кастомизированный образ ESXi с уже вшитым драйвером сетевого USB-адаптера. Просто раскомментируйте строчку с нужной версией драйвера:
# ESXi 7.0 Image with USB NIC Fling 1.6:
$baseProfile = "ESXi-7.0.0-15843807-standard" # See https://www.virten.net/vmware/vmware-esxi-image-profiles/ for available Image Profiles
$usbFling = "ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip" # Uncomment for ESXi 7.0
#$usbFling = "ESXi670-VMKUSB-NIC-FLING-39203948-offline_bundle-16780994.zip" # Uncomment for ESXi 6.7
#$usbFling = "ESXi650-VMKUSB-NIC-FLING-39176435-offline_bundle-16775917.zip" # Uncomment for ESXi 6.5
При установке VMware ESXi на хост, где есть только USB сетевые адаптеры, процесс может зависнуть на 81%. В этом случае почитайте вот эту статью.
Кстати, ваши USB-адаптеры лучше всего пометить наклейками. Автор предлагает указать имя хоста ESXi, MAC-адрес адаптера и его номер vusbX:
Номер виртуального vusbX не сохраняется при перезагрузках. Начиная с версии драйвера 1.6 можно закрепить MAC-адрес за нужным vusbX. Сначала найдем наш адаптер:
# esxcli network nic list |grep vusb |awk '{print $1, $8}'
vusb0 00:23:54:8c:43:45
vusb1 a0:ce:c8:cd:3d:5d
Затем сделаем статический маппинг адаптеров с использованием модуля vmkusb_nic_fling:
# esxcli system module parameters set -p "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d" -m vmkusb_nic_fling
В данной команде нужно перечислить все адаптеры через пробел (если вы вызываете ее второй раз, то нужно переуказать каждый из адаптеров, иначе маппинг сбросится).
Далее нужно проверить маппинги с помощью команды:
# esxcli system module parameters list -m vmkusb_nic_fling
Name Type Value Description
-------------------------- ------ ----------------- -----------
usbCdromPassthroughEnabled int Enable USB CDROM device for USB passtrough: 0 No, 1 Yes
vusb0_mac string 00:23:54:8c:43:45 persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac string a0:ce:c8:cd:3d:5d persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac string persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac string persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac string persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac string persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac string persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac string persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx
Если вы хотите сделать текущий маппинг постоянным, то используйте команду:
# esxcli system module parameters set -p "$(esxcli network nic list |grep vusb |awk '{print $1 "_mac=" $8}' | awk 1 ORS=' ')" -m vmkusb_nic_fling
Также статические маппинги можно сделать и через PowerCLI. Выводим адаптеры:
PS> Get-VMHostNetworkAdapter -VMHost esx2.virten.lab -Physical -Name vusb* |select Name,Mac
Name Mac
---- ---
vusb0 00:23:54:8c:43:45
vusb1 a0:ce:c8:cd:3d:5d
Далее проводим операцию vMotion виртуальной машины между хостами ESXi. Результат таков:
Очевидно, кросс-соединение на адаптерах 2.5G рулит.
Проверка совместимости
Не все сетевые адаптеры USB поддерживаются нативным драйвером. Их актуальный список всегда можно найти вот тут. Вот эти адаптеры точно работают:
Адаптеры доступны в форм-факторах USB-A и USB-C. Между ними есть переходники.
Если вам нужно высокоскоростное соединение (multi-gigabit) между несколькими хостами, можно посмотреть на следующие коммутаторы:
MikroTik CRS305-1G-4S+IN ($130 USD) - 4 порта
MikroTik CRS309-1G-8S+IN ($260 USD) - 8 портов
Netgear MS510TX ($260 USD) - 10 портов
TRENDnet TEG-30102WS ($450 USD) - 10 портов
Самое быстрое и дешевое соединение между двумя хостами ESXi - соединить адаптеры патч-кордом напрямую:
Проверяйте параметр MTU size, когда включаете Jumbo Frames
Если вы меняете размер MTU на виртуальном коммутаторе, он принудительно меняется на всех подключенных к нему физических сетевых адаптерах. Имейте в виду, что эти адаптеры должны поддерживать выставляемый MTU size.
Посмотреть размер MTU можно следующей командой:
[root@esx4:~] esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 0000:00:1f.6 ne1000 Up 1000Mbps Full 00:1f:c6:9c:47:13 1500 Intel Corporation Ethernet Connection (2) I219-LM
vusb0 Pseudo uether Up 1000Mbps Full 00:24:9b:1a:bd:18 1600 ASIX Elec. Corp. AX88179
vusb1 Pseudo uether Up 1000Mbps Full 00:24:9b:1a:bd:19 1500 ASIX Elec. Corp. AX88179
В данном примере MTU size настроен как 1600, что подходит для адаптеров (и работает для сети NSX-T). Если же вы поставите его в 9000, то увидите в vmkernel.log ошибки для dvSwitch о том, что такой размер не поддерживается устройством:
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: vmkusb: Set MTU 9000 is not supported: Failure
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: Uplink: 16632: Failed to set MTU to 9000 on vusb0
Если вы хотите проверить корректность вашего MTU size, то можно использовать команду ping с размером пакета MTU-28 байт (8 байт на заголовок ICMP и 20 байт на заголовок IP). Таким образом, для MTU size 1600 используйте число 1572:
[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1572 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1572 data bytes
1580 bytes from 192.168.225.10: icmp_seq=0 ttl=64 time=0.680 ms
[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1573 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1573 data bytes
sendto() failed (Message too long)
Это статья нашего спонсора - компании ИТ-ГРАД, предоставляющей в аренду виртуальные машины из облака. Гиперконвергентность – быстрорастущий сегмент СХД. Переход от традиционной архитектуры к HCI выбирают все больше компаний. Хотите узнать почему? В статье мы ответим на этот вопрос и расскажем для каких задач подходит VMware vSAN...
Иногда в кластере хранилищ VMware vSAN случается такая ситуация, что один из хостов ESXi оказывается "пустым", то есть не содержит компонентов виртуальных машин. При этом хранилища остальных хостов в кластере могут быть загружены почти полностью.
В этом случае надо посмотреть на интерфейс vSphere Client в разделе vSAN health check - там может быть такое сообщение для проблемного хоста:
vSAN node decommission state
Означает это, что хост находится в режиме обслуживания с точки зрения vSAN (Node Decommission State). При этом, например, с точки зрения хостов ESXi кластера VMware vSphere / HA он может не быть в maintenance mode. Поэтому может сложиться впечатление, что хост просто не принимает дисковые объекты по каким-то причинам.
Это состояние рассинхрона кластера vSphere и кластера vSAN. Лечится следующей командой по SSH, которая выведет узел vSAN из режима обслуживания, после чего он оживет на прием компонентов:
localcli vsan maintenancemode cancel
Также вы можете кликнуть правой кнопкой на хосте ESXi, перевести его в режим обслуживания, а потом вернуть обратно:
Это отменит и перевод в режим обслуживания vSAN, после чего хост сможет размещать дисковые объекты виртуальных машин (для этого надо запустить операцию Rebalance). Более подробно об этом в KB 51464.
Несмотря на то, что компания VMware представила версию средства для создания отказоустойчивых хранилищ vSAN 6.5 еще в 2016 году, многие крупные компании продолжают ей пользоваться. Между тем, надо понимать, что скоро браузеры отключат поддержку Flash, и все консоли на базе этой технологии (а именно на ней работает старый vSphere Web Client) просто прекратят работать (в Chrome это запланировано на декабрь этого года).
Чтобы вы могли и дальше использовать vSAN 6.5, нужно накатить патч vSAN 6.6.1 Patch 05 (вышел еще 30 июля), в котором добавлена поддержка технологии HTML5, поддерживающейся всеми современными браузерами. О возможностях vSAN 6.6.1 мы писали вот тут.
В новом апдейте vSAN 6.6.1 на базе мажорной версии 6.5 есть следующие нововведения:
Отчеты о производительности вы можете найти в Cluster > вкладка Monitor > секция vSAN > Performance
Добавлена панель общей информации в разделе Virtual object, показывающая размещение и доступность объектов в кластере. Также можно фильтровать список по статусу и типу объектов.
В разделе Virtual Objects/ View data placement есть чекбокс "Group components by host placement", который дает возможность увидеть состояние компонентов данных и быстрее обнаружить потенциальные проблемы на хостах ESXi.
Также из блога VMware мы утянули вот такое видео с обзором интерфейса HTML5 для vSAN 6.6.1:
RSS
